@baentsch Although I've added hybrid signatures to OQS-BoringSSL, I prefer to keep the clienthello size small by not enabling them by default. However, we do need to test these hybrid signature algorithms. Since we only have four types—p256_*, p384_*, p521_*, and rsa3072_*—I've decided to enable one algorithm from each type for testing purposes. Specifically, I've enabled:

• p256_mldsa44
• p384_mldsa65
• p521_mldsa87
• rsa3072_falcon512

This setup is easy to remember: mldsa with elliptic curves and falcon with rsa3072. It's a clean and straightforward way to track which algorithms are enabled.

@baentsch Do you have any additional comments? If not, I'll go ahead and merge this PR. I'll update the commit message to include that "we changed the default hybrid signature algorithms."

@baentsch Do you have any additional comments? If not, I'll go ahead and merge this PR. I'll update the commit message to include that "we changed the default hybrid signature algorithms."

And that actually is the purpose of the PR, no "sync with liboqs/oqsprovider", right? Wouldn't it be fair to say that this PR creates a stronger difference between oqsprovider and boringssl even? If so, should this be documented somewhere so users understand (the rationale)?

@baentsch It syncs with oqs-provider by updating the ML-KEM code points.
Anyway I'll label it as "update algorithms," and the commit message will be:

• Add CROSS
• Update ML-KEM
• Change default enabled hybrid signature algorithms

I think it's clear that oqs-boringssl supports only a subset of algorithms available in oqs-provider.